home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Language/OS - Multiplatform Resource Library
/
LANGUAGE OS.iso
/
cpp_libs
/
varia
/
dynload.lha
/
dynload
/
README
< prev
next >
Wrap
Text File
|
1993-08-08
|
5KB
|
139 lines
DESCRIPTION
This is a dynamic loader for Sun3 and Sun4. The interface is very
simple. There are three main functions:
setArg0(const char *) - Call with argv[0] to find main object file
bool loadFile(const char *fileName) - Load an object file
long value(const char *sym, int bad=-1) - Find symbol value
This loader reads the object file into memory and does the relocation
on its own. This makes it fast and it works even if the main object
file is dynamically linked (the loaded object file can make calls into
the shared libraries).
The advantages of this loader over SunOS 4.1 dlopen() or "ld -A":
1) Works with normal object files (does not use shared libraries)
2) Works if the main object file is dynamically linked.
3) Loaded object can have symbol dependencies into main file or
previously loaded object files.
4) It is much faster than the "ld -A" approach.
The disadvantages:
1) It will not load every type of file since I have not found ways
of making all relocation types in Sun object files.
Other things to note:
1) It is written in C++.
2) It is free and unsupported (although I would like to hear of bugs).
HISTORY
This is the second release of my dynamic loader for Sun3/4 C++ OS 4.0.
I have tested this on Sun3/280 OS 4.0.3 and Sun4/260 OS 4.0.3.
This is as-is software. You hook it up to your heart-lung machine and
you may be sorry, but I won't be responsible.
I can be reached at
Glenn Gribble glenn@synaptics.com uunet!synaptx!glenn
Synaptics, Inc. (408) 434-0110
2860 Zanker Road, Suite 105 (408) 434-9819 FAX
San Jose, CA 95134
Some general notes:
HOW TO INSTALL THE LOADER
This loader will work on a Sun3 and Sun4. To make the test programs, just
unshar this shar file and type make.
After the make, type 'loadtest' to run the test program. The test program
loads 'sub.o' and prints out a few messages. Read 'loadtest.cxx' for more
info.
PSEUDO MAN PAGES
NAME
loader - A dynamic loader
SYNOPSIS
#include "loader.h"
void setArg0(const char *arg0);
bool loadFile(const char *dot_oh_file);
long value(const char *sym, int bad=-1);
DESCRIPTION
setArg0() must be called with argv[0] so that the loader can find the
executable file associated with this program (the loader needs the
symbols in this file). setArg0() uses the value of the enviroment
variable PATH to find what file the program probably came from.
loadFile() loads an object file into memory and calls the constructors
of that file. The first time loadFile is called, it initialize the
dynamic load enviroment by loading the symbols for the running program,
loading the symbols for the shared libraries, and finding the location
of the shared libraries in memory.
value() returns the value of a symbol. For instance to find the location
of a function "myFunc" in memory, do this (watch out for C++ name mangling):
long v = value("myFunc",-1);
if (v == -1)
printf("myFunc not found\n");
else
printf("myFunc is %x\n", v);
Note that the value of a symbol may change after a new file is loadFile()d,
because this file may re-define any symbol.
NAME
error - formatted error message printing
SYNOPSIS
#include "loader.h"
void error(const char *fmt ...);
void warn(const char *fmt ...);
void info(const char *fmt ...);
DESCRIPTION
Print out formatted error/warning/informational messages. These routines
can be replaced with more complex routines that print out input file names
or whatever.
LOADER THEORY OF OPERATION
First, the main object file is located by looking for it on the path.
(This is what setArg0() does.)
The first time loadFile() is called the shared libraries are located
using information contained in __DYNAMIC and their symbol tables are
loaded into memory. The symbol table for the main program is loaded
into memory after the shared libraries. The reverse order is necessary
because a stack of symbols is built up. During lookup, a symbol is
first looked up in the loaded object files (most recently loaded first),
then the main program, and finally the shared libraries.
At this point, the loader is ready to load an object file.
The text and data segments of the object file are loaded into memory
and space for the bss segment is allocated just after the data segment.
The symbol table is loaded. Finally the relocation segments are loaded
and relocation is performed. After relocation, the relocation segments
are unloaded as they are no longer needed. The symbol table is retained.
Finally, any symbols that look like the symbols for file-level
constructors (start with "___sti__") are evaluated and the associated
function called.
WHAT'S WRONG WITH THIS PICTURE? (or things to do)
The loader can not cope with certain kinds of relocations. It should
be changed to support these other kinds, but so far I have not found
one in any of my files so I am not sure what the other kinds mean.
Symbol table searching is done linearly at each level in the stack
of symbol tables. This could be done in a more intelligent fashion,
but it has not been a real speed problem. It might be a problem if
many symbol lookups were being performed.